Ja, hallo. Wir hatten das letzte Mal angefangen, uns um diese Kauber-Mittelwehr-Architektur zu kümmern,

die ja doch eine Basis ist für eine ganze Reihe von Architekturen, die sich eben mit verteilten

objektoentierten Systemen beschäftigen. Und deswegen wollte ich da ja einen kurzen Überblick drüber

geben. So gegen Ende der letzten Vorlesung hatten wir uns nochmal angeguckt, wieso die

verschiedenen Komponenten in dieser Mittelwehr-Architektur entstehen. Und ein zentrales

Element von dieser Kauber-Architektur ist ja diese Interface Definition Language, in der die

Schnittstellen der Objekte beschrieben werden, also die Schnittstellen der Server-Objekte,

damit eben diese Stubs, die für den Aufruf erforderlich sind, automatisch generiert werden

können. Und vor allem wichtig bei der Kauber-IDL auch, dass dadurch nicht nur eine Abstraktion oder

eine Unabhängigkeit von der jeweiligen Plattform, vom Betriebssystem, vom Kommunikationssystem

entsteht, sondern vor allem auch eine Unabhängigkeit von der Programmiersprache. Es gibt also Anbindungen

von diesen Schnittstellen, die in der IDL beschrieben werden, an unterschiedliche

Programmiersprachen, sodass also Client und Server auch eben in unterschiedlichen Sprachen

formuliert sein können. So, aus dieser IDL wird dann eben über einen Pre-Compiler letztendlich

werden diese Stubs generiert. Es werden die Client-Stubs generiert, die dann auf der Client-Seite

einfach zum Client dazugebunden werden können. In vielen Fällen wird es statisch gemacht,

das heißt auf der Client-Seite mache ich ganz normale Objekte, Methodenaufrufe und der Stub

verpackt es dann eben und verschickt es. Auf der Server-Seite ist es natürlich ein bisschen komplexer,

denn da reicht es natürlich nicht einfach, den Stub zur Anwendung hinzuzubinden, sondern

dieser Stub ist letztendlich eigentlich ein Gerüst, in das das Server-Objekt dann eingebaut

werden kann und deswegen heißt der Server-Stub oft auch Skeleton und in diese Skeleton wird dann die

eigentliche Objektimplementierung auf Server-Seite eingebaut. Das ist in vielen Fällen dann doch

ein Stück weit auch eben Handarbeit. Man bekommt also Codefragmente zur Verfügung gestellt von

dem IDL-Compiler und muss die dann entsprechend eben ergänzen. Und was daraus entsteht, ist dann

dieser Servant letztendlich ein remote aufruffähiges Ding auf der Server-Seite. Der wird dann natürlich

auch wieder übersetzt und dadurch entsteht dann der Servant-Code. Also das Servant ist letztendlich

das remote aufrufbare Objekt auf der Server-Seite, das tatsächliche Objekt. Und die Frage ist jetzt

natürlich, wie bindet man das Ganze zusammen? Und auf der Server-Seite funktioniert das Ganze so,

dass irgendwie natürlich dieses Objekt erst mal erzeugt werden muss. Da will ich gar nicht im

Einzelnen darauf eingehen, diese Objekterzeugung. Auch dafür gibt es spezielle Dienste und typischerweise

gibt es also dann einen speziellen Dienst für die Erzeugung. Diesen Dienst nennt man auch Factory,

ein Object Factory, die letztendlich Methoden anbietet, um konkrete Servants zu erzeugen.

So und wenn die das dann gemacht hat, dann muss dieser Servant natürlich dort noch so verdrahtet

werden, dass er dann auch aufrufbar wird. Und das passiert dadurch, dass das Objekt, das ist das

Servant-Objekt am Object Request Broker, also an dieser zentralen Infrastruktur, die die Kommunikation

bereitstellt, registriert wird. Ganz konkret ist es gar nicht der ORB, sondern es ist der sogenannte

Portable Object Adapter. Das ist letztendlich die Vermittlungskomponente auf der Server-Seite für

alle ankommenden Aufrufe. Und an dieser Vermittlungskomponente, an dem POA, registriert

man eben so ein serverseitiges Objekt. Und der POA oder der ORB erzeugt dann eine Objektreferenz,

eine Interoperable Object Reference, letztendlich so eine Art Fat Pointer oder also ein Ding, das

ich eben im Netzwerk verwenden kann, um Aufrufe zu machen. Und das Binden des Clients an das Server-Objekt

passiert letztendlich dadurch, dass der Client irgendwie diese Interoperable Object Reference

bekommt. Und da gibt es dann mehrere Möglichkeiten. Eine Möglichkeit ist, der Client hat irgendeinen

Methodenaufruf gemacht, zum Beispiel an die Factory, und dort um das Erzeugen eines Objekts

gebeten. Und er bekommt als Ergebnis so eine IOR zurück und kann die dann verwenden. In vielen

Fällen ist es aber auch so, dass so ein Objekt gar nicht gerade erst vom Client erzeugt wird,

sondern dass es das schon gibt. Irgendjemand anderes hat es halt irgendwann mal erzeugt. Und

der Client muss jetzt natürlich irgendwie dann zu dieser Interoperable Object Reference kommen. Und

eine Möglichkeit ist, dieses Objekt hat einen Namen und es gibt einen Name Service, und der

Client fragt einfach den Name Service. Und die typische Operation auf einem Name Service ist so